← Return to doc.sitecore.com

  Multiple Developers Case
Prev Next
Print this page (opens in new window) Print
/upload/sdn5/developer/team development/team_development 2.png 

Test1, … TestN and Edit1,… EditN, as well as User Workstations are computers which do not require any special software. They are just accessing corresponding servers.

This section describes a working cycle of a team consisting of more than one developer.

1.  Installation

The development server should have the following components installed:

The developer’s workstation should have the following components installed:

Developers must have the Sitecore Installation on their workstations in order to be able to debug applications simultaneously.

1.1.  Common Practice

The following practice may be implemented on a developer’s server:

Two types of Sitecore databases are created: the Clean and the Dirty one.

The Clean databases contain final versions of the content. The Sitecore installation on the Development Server works with Clean Databases. Developers edit the Items in the Clean database directly in the Sitecore client. The Version Control of the content is managed by Sitecore.

Dirty databases are used by developers as a ground for testing and experiments. Local Sitecore Installations are connected to the Dirty database.

In general, it is safer to create Items directly in the Clean database, as long as some locked Items may be overwritten if a developer uses a package.

The Dirty database is restored from the Clean instance when needed.

Important Note: use the Dirty database for testing purposes only! The setup executed when multiple Sitecore installations are working with the same databases may result in data loss due to the caching issue.

Such setup allows developers to develop and debug applications simultaneously. Two separate database sets (Clean and Dirty) provide a good testing ground and a safety for the final content site.

Developers may also use local databases if there is no need to work with the same content in the Dirty database.

All the source code (.html layouts, code behind, etc.) version control is performed by the Source Control System.

Note: To set up the 'Dirty' databases you will need a copy of ALL seven of the Sitecore databases.

2.  Typical Work Cycle

If you are a developer, your typical work cycle may look like this:

  1. Check-out the source code you need for the project from the Source Control System. Create and modify content Items in the Dirty database on the server.

    The source code version control is performed in the common way 

    Continue working with the Dirty database until you’ve finished your debugging and testing procedures. Version control cannot be implemented on the Dirty database to the full, as long as all developers may create/modify Items programmatically at the same time.

  2. Prepare the content which needs to be transferred to the Clean database. It may be required to ask other developers not to edit the content in the Dirty database while you prepare and test the package.

  3. Check in the code (The changes should appear in the source code repository first and then may be released to the main server).

  4. Backup the Clean database.

  5. Update the Clean database on the Development server using the Sitecore installation on the server.

  6. Send a broadcast note to other members of the team saying that some items were added/modified. Point to the package you’ve created (optional).

  7. Another developer may now perform actions 1 and 2 and start working locally.

2.1.  Caching Issue

Sitecore V5 implements cache for reading. When several Sitecore installations point to the same databases (Dirty databases in our case), the developers may see invalid content. This is caused by the fact that caches (as well as sessions) are handled separately for each installation.

Every code recompilation causes site restart, which clears the cache. Code is recompiled quite often during the development process, that’s why the problem described above may not show up very often. But it may be really severe when several developers install packages simultaneously or create items programmatically.

That’s why the Clean database should only be modified with the Development server Sitecore installation. For instance, when several packages are installed by different users simultaneously within one Sitecore installation, package installations are queued and no database breach occurs.


Prev Next